home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 2473 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB

  1. Path: sourcery.han.de!not-for-mail
  2. Newsgroups: comp.sys.amiga.misc
  3. References: <4cpmlv$obe@ousrvr3.oulu.fi>
  4. From: "Olaf Barthel" <olsen@sourcery.han.de>
  5. Date: Sun, 21 Jan 1996 16:41:48 +0100
  6. X-NewsReader: IntuiNews 1.3a (7.9.95)
  7. Subject: Re: OS features
  8. Message-ID: <13213500@sourcery.han.de>
  9.  
  10. In Article <4cpmlv$obe@ousrvr3.oulu.fi>, Teijo Kinnunen <kinnunen@stekt.oulu.fi> wrote:
  11. > [..]
  12. > How about something like this (just an idea):
  13. > All "old" applications run in a single memory space, with no protection
  14. > between them, if one of them crashes, this virtual machine may crash bringing
  15. > possibly down all "old" programs with it. They can communicate with each
  16. > other using shared memory & messages, as they do today.
  17. > "New" programs (aware of memory protection) would each run in their own
  18. > protected memory spaces (with resource tracking, hopefully). They could
  19. > communicate with other processes only through new, safe OS calls (not by
  20. > sharing memory, as today). These new programs could crash without harming
  21. > any other processes, and they could be completely killed releasing all
  22. > the resources they used.
  23. > "Old" programs should be convertable to "new" with relatively few changes,
  24. > mostly concerning interprocess messaging, and recompilation.
  25.  
  26.    That's the standard idea to approach the problem. Even Apple hit upon it
  27. with their Copland compatibility box, or so I'm told. I don't know for certain
  28. how Apple weaves their magic, but as they always kept the mechanisms behind
  29. their OS pretty much hidden (for good reasons) they probably added the code
  30. backing the `new' way of doing things in such a way to allow for an easy
  31. transition.
  32.    I'd say that running multiple sessions of AmigaOS on the same machine
  33. is not an impossible prospect. The question is just how much of the old AmigaOS
  34. API will have to be adapted or needs to be declared obsolete. Personally, I
  35. object to the multi-session solution as it's neither elegant nor shows an
  36. easy path to travel when developing software.
  37.    Look, I don't want to program for a machine which is absolutely unforgiving
  38. for every slight mistake I make. A machine that crashes on every wrong step is
  39. just as dangerous as machine which guns every program for the same reason the
  40. other machine would have crashed. I'm not implying that every badly written
  41. program should get away with murder, I want error tolerance.
  42.